This invention relates in general to electronic data interchange (EDI) systems, and more specifically to a method and apparatus for remotely and electronically entering invoices and for validating said invoices in an invoice processing system.
For about ten years businesses have attempted to widely implement a technology called Electronic Data Interchange (EDI) with little success. EDI is an electronic data communication process allowing businesses to electronically exchange documents. Successful EDI systems reduce the amount of paper documents a business receives and processes, which in turn reduces the need for clerical overhead and consequently reduces overall transaction costs.
EDI has had a very limited acceptance in the marketplace to date. Typically, EDI consists of a host company investing hundreds of thousands, or millions, of dollars to bring an EDI system on line. Once available, host companies, unfortunately, have only been able to persuade a very small percentage of their vendors to participate in the EDI document exchange process. The main reasons for this include the following. EDI remains very expensive for most companies to implement, mainly do to its complex implementation. Therefore, only the largest of companies can afford to implement a full EDI system.
Further, because EDI is so technically complicated to support, only companies with well developed technical staff and computer systems can support the requirements of a conventional EDI implementation. Furthermore, because, EDI traditionally has been costly to implement, only companies with very large volumes of documents to handle can justify the large costs, which precludes a very large number of smaller businesses from considering an EDI implementation. Additionally, EDI is a closed loop system implementation requiring close integration between a client""s accounting computer system and a vendor""s accounting computer system. Consequently, the integration between a client""s accounting computer system and a vendor""s accounting computer system has been difficult, requiring virtually a custom accounting computer interface between the client and each of its vendors. For these reasons, and others, many companies have been reluctant to implement EDI systems. In a real world example, a company had spent upwards of 2 million dollars to implement an EDI computer system, but after five years of development had only five out of thirty thousand (30,000) vendors communicating via the EDI implementation. Although EDI originally was intended to reduce transactional costs and make it easy to integrate between client and vendor computer systems, in actuality, the prohibitive costs to implement and support a conventional EDI system have kept most companies from utilizing EDI implementations in their financial transactions.
An exemplary prior art EDI system is shown in FIG. 1. Company 1, in this example, communicates with Company 2 via a proprietary EDI value added network 102. This value added network 102 requires specialized equipment and customized interfacing between each pair of companies to effect communication of electronic documents utilizing EDI implementation. Conventional EDI systems normally require at each company interface to the value added network a translation of document format between an EDI proprietary communication format and the company""s internal proprietary document format for its accounting computer system.
In a typical transaction, Company 1 creates a purchase order 104, packages the purchase order document in EDI format, at step 106, as required by a particular vendor company (Company 2), and then Company 1 uploads the document into the value added network 102 via a Company 1 EDI value added network interface site 108. The document then travels across the value added network 102 until it arrives at a Company 2 EDI value added network site interface 110. Company 2 then translates the document received, at step 112 from the EDI format into the internal proprietary document format required by Company 2""s accounting computer system. Company 2 then creates a purchase order document, at step 114, and delivers the ordered product, at step 116. Then Company 2 creates an account receivable invoice at step 118. Company 2 then packages its internally created invoice document into an EDI format, at step 120, and uploads the document into the value added network 102 via the Company 2""s EDI value added network site 122. The document then travels through the value added network 102 and arrives at Company 1""s EDI value added network site, at step 124.
Company 1 then translates the received document, at step 126, from the EDI format to the Company 1 internal document format for Company 1""s accounting computer system. Company 1 then creates an accounts payable invoice document, at step 128 from the translated EDI format document. Company 1""s accounting computer system then updates its purchase order system, at step 130, to reconcile the received invoice information with a purchase order information that may have been originally created by Company 1.
If Company 1""s system determines that there is a match between invoice information received and a purchase order information originally created by Company 1, then Company 1""s accounting computer system authorizes payment, at step 132, to forward a payment to a particular vendor that sent the invoice information. Company 1""s accounting computer system then prepares an accounts payable document confirming payment authorization and packages the document in EDI format and uploads the document into the value added network 102 via a Company 1 EDI value added network site 134. This electronic document then travels through the value added network 102 until it arrives at Company 2""s EDI value added network site, at step 136. Company 2""s accounting computer system then translates the EDI formatted document, at step 138, into its internal document format for its accounting computer system. Subsequently, Company 2""s accounting computer system, at step 140, updates its internal accounts receivable records to reconcile between the invoice information that Company 2""s accounts receivable created, at step 118, with the payment authorization confirmation document received from Company 1.
As can been seen, from this sequence of steps to affect a single transaction between Company 1 and Company 2, the conventional EDI implementation suffers from a number of evident draw backs. First, it requires communication via a proprietary and complex value added network 102 for all transaction documents. Second, Company 1 and Company 2 must repeatedly translate documents from an internal accounting document format to/from a customized EDI format packaged from the other company. This format interchange tends to be customized and very particular between Company 1 and Company 2""s accounting computer systems. Additional companies would require similar additional customization to be able to communicate documents between Company 1 and/or Company 2. Further, the technical complexity and customization required to interface Company 1""s accounting computer system to Company 2""s accounting computer system via the EDI value added network through interface sites significantly burdens each company""s technical resources to the point that it makes EDI implementation prohibitively expensive for most companies, except for the most technically sophisticated and well financed large companies.
Thus, there exists a need for an alternative invoice processing system that can fulfill the original promises of EDI for standard and efficient document communication while maintaining the cost of implementation affordable for most companies.